Summary

Fixes the generated C# (@typespec/http-client-csharp) protocol method call site passing arguments to the CreateRequest builder in the wrong positional order.

Reported in Azure/azure-sdk-for-net#60160 for Key Vault updateSecret / updateCertificate.

Root cause

The protocol method orders its parameters required-first (optional parameters and the request options/context parameter are moved to the end so they can carry default values). The CreateRequest builder keeps the operation declaration order. When an optional parameter appears before a required body parameter, these two orders diverge.

The call site forwarded the protocol method's parameters to CreateRequest positionally, so the arguments bound to the wrong builder parameters. For Key Vault updateSecret this routed the RequestContent into the secret-version URL path slot:

// builder (correct)
internal HttpMessage CreateUpdateSecretRequest(string secretName, string secretVersion, RequestContent content, RequestContext context)

// call site (bug) — content and secretVersion swapped
this.CreateUpdateSecretRequest(secretName, content, secretVersion, context);

The resulting PATCH URL became /secrets/{name}/{garbage-content-bytes} and 404'd.

Fix

Map each CreateRequest argument to the protocol parameter with the same name, so values are passed in the order the builder expects (falling back to the previous positional behavior if names can't be reconciled).

Tests

• New regression test ProtocolMethodCallsCreateRequestWithArgumentsInBuilderOrder reproduces the optional-path-before-required-body scenario and verifies the call site uses the builder's order.
• Updated the TestMultipartClient_UploadMethods_OptionalBody baseline: it previously showed the sync and async Upload overloads passing arguments to the same CreateUploadRequest builder in different orders — i.e. the same latent bug. Both now correctly use (content, contentType, options).
• Full Microsoft.TypeSpec.Generator.ClientModel suite passes (1440 tests).

Fixes Azure/azure-sdk-for-net#60160